『インタラクティブな分析アプリケーションを構築しよう』セッションに考える、データレイクへのインタラクティブな分析インターフェースの活用 #reinvent #ANT209

データアナリティクス事業本部の鈴木です。

ちょっと時間が経ちましたが、AWS re:Invent 2022の、セッション番号ANT209の『Build interactive analytics applications』を聴講したのでレポートです。Amazon Athena for Apache Sparkの紹介セッションです。

来週7/19（水）のDevelopersIO 2023 大阪にて、Amazon Athena for Apache Sparkに関する発表を予定しています。

自分でAmazon Athena for Apache Sparkを動かしていろいろと検証をしているのですが、改めてre:Invent 2022のセッションにてどのような紹介がされていたか勉強しました。

また、その内容を受けてどのような使い方ができそうかや気をつけたい点を、特にシステム的な観点で自分なりに考えてみたので後半ではそれをまとめました。

セッション内容

セッションについて

登壇者

• Ravi Ramanujam, Principal Engineer, FINRA
• Raj Devnath, Product manager, AWS

Session level

200 - Intermediate

Session type

Breakout Session

動画

スライドPDF

AWS Events Contentより確認しました。

• https://d1.awsstatic.com/events/Summits/reinvent2022/ANT209_Build-interactive-analytics-applications.pdf

セッション概要

Amazon Athenaの新しいフレームワークのサポートを受けて、より速く、よりシンプルに、最も効果的に分析アプリケーションを実行する方法を学びます。

私のまとめ

このセッションはAmazon Athena for Apache Sparkの機能紹介と、FINRA社での利用事例の2つの紹介がありました。簡単にですが、ポイントと思った点を箇条書きでまとめます。

Amazon Athena for Apache Sparkの機能紹介

• SQLより表現力が高い仕組みをデータ分析に使いたいケースがあり、Amazon Athena for Apache SparkではPySparkを使って処理を記述できる。
• Pythonはライブラリを使うことができる点で強みがある。
• 保守性の観点で、Pythonで記述することでSQLよりも管理しやすいケースがある。
• PythonそのままだとSQLエンジンにあるような処理の最適化はできず、実行速度面では不利になるため、PySparkを使う。
• Sparkのハードウェアからの構築と運用は、ハードウェアおよびソフトウェア設定の両面で非常に難度が高いため、マネージドサービスに大きなメリットがある。
• Athena for Apache Sparkは、Sparkアプリケーションの起動が速く、分析にかかるオーバーヘッドの時間が小さい。
• AWS Glueのデータカタログともシームレスに連携できる。
• Athena for Apache Sparkはインタラクティブなデータ分析ワークロードに最適化されている。
• ワークグループの設定を通して、Sparkアプリケーションから分析対象のリソースへのアクセス制限ができる。
• Athenaノートブックを使ってSparkアプリケーションを実行できる。ノートブックのExportおよびImportが可能なため、分析内容を開発チーム内でシェアできる。

事例紹介

• 約500ペタバイト以上のデータを格納したデータレイクを保持しており、そのデータレイク内での事例となる。
• データアナリスト、ビジネスユーザーの２つのペルソナを想定して利用した。
• ビジネスユーザーはデータから市場をよりよく調査し、何がトレンドなのかを確認できる。
• データアナリストはデータからよりよい特徴量を探索できる。
• EMRを使ったETL処理を使った場合、分散処理システムに追加する資源の調達がオーバーヘッドになってしまい、アジリティが低くなってしまうケースがある。
• Athena for Apache SparkはSparkのハードウェア部分はマネージドのため、起動するだけでAthenaノートブックから巨大なデータに対しても分析が実行できることがポイントとなる。

考察

以降は、このセッションの内容と、私の技術検証を踏まえた考察になります。一部セッションの資料を借用しますが、基本的には私個人の意見となります。

データの読み込み・書き込み方法について

データはSparkで直接読み込むこともできますし、Glueデータカタログを経由してGlueテーブルからクエリするように取得することも可能です。

分析結果はGlueデータカタログにテーブルとして登録しておくこともできます。この場合、アドホックにどんどん作っているとたくさんのデータベースやテーブルが多くできてしまう可能性があるので、ある程度使い方のルールや棚卸しの頻度を決めておくとよいかもしれません。

なお、Hiveテーブルフォーマット以外のテーブルフォーマットには、先日対応しました。これについては以下の記事で紹介しました。

サービスの強みについて

上記の『Use case: Interactive data exploration』の通りですが、専門性が必要なEMRのような分散処理システムの準備やデータエンジニアによる変換パイプライン開発を待たずして、とりあえずAthena for Apache Sparkを使えばデータレイクからそのままデータを取得して分析・可視化を始められるという点が、大きな強みだと思いました。

この点は、事例セッションでも言及がされており、この機能を革新的なものにする理由の一つだと思います。

例えば、極端には以下のような構成だけで大規模なデータに対する分析が開始できます。

もちろん、簡潔な構成でもデータ分析基盤としてのシステム設計や運用設計などはしっかりしておく必要があります。

特に気になるのは以下のような点です。

• S3バケット上にどのような配置でデータをアップロードするかというデータレイクの設計
• 権限制御をどのように実現するか、ワークグループに割当てるIAMロールの権限やワークグループへのアクセス権限の設計
• 料金面でのルールの策定

一時的にとはいえ大きなサイズのコンピューティングリソースを確保するため、料金面での取り決めは重要になりそうです。

権限制御について

前述しましたが、ノートブックで実行されるSparkアプリケーションの権限はワークグループに設定したIAMロールで制御します。

どのユーザーがどのワークグループにアクセスしてよいかは、IAMユーザーもしくはスイッチしているIAMロールのポリシーにて制御する形となりそうです。

このリソースについても、適当に作っているとどんどん数が増えてしまいそうなので、定期的な棚卸しや管理は必須になりそうです。

料金について

料金については、使用したDPUでの課金ですが、単価は現状はリージョンによって異なります。例えばバージニア北部リージョンだと0.35USD per DPU-hour billed per minuteですが、東京リージョンだと0.50USD per DPU-hour billed per minuteです。これは記事執筆時点での価格になります。この価格差については注意が必要になります。

こう使えるとよさそう

私としては、以下の2つの使い方を考えています。共通する点としては、データレイクのアドホックな分析用途としてAthena for Apache Sparkを使う点です。Athena for Apache Sparkで要件に対してデータレイクにあるデータの検証を行い、長期運用のためにはAWS Glueなど別のサービスでETLのアプリケーションなどを仕立ててデータマートを作るのがよいように考えています。

データマート作成のための検証

データマート層のデータ作成のための検証で、データレイク層の分析に利用する用途です。

例えば以下のような構成です。

データレイクでは、レイク層にあるさまざまな生データを加工し、データマートとして自アカウント内はもちろんのこと、ほかのアカウントのユーザーにも活用してもらうと思います。例えば、自アカウントにあるログデータを加工して監査や分析に使えるデータマートを作るといったイメージです。

一方で、本当に意味のあるデータマートとして仕立てられるのかは、一度データを分析してみないと分からないと思います。これまではデータのサイズが巨大な場合は、気軽に分析することはできず、データ分析基盤に連携して加工してもらったり、Athena SQLやGlue Studioで作ったETLジョブで加工したものを、どこかにダウンロードして可視化・評価して......とある程度手間がかかっていたのが普通だと思います。この場合、開発のリードタイムはもちろんのこと、プロジェクトの建て付けとしてデータエンジニアの工数が空くまで、さらに長い時間待つ必要があるかもしれません。

Amazon Athena for Apache Sparkを使えば、誰でも大規模なデータに対して柔軟な処理を実行し、ノートブックを通して洞察を得ることができるようになります。

これにより、専用の分析資源を持たないAWSアカウントでも、検証・作成したデータマートテーブルをデータカタログとして公開してほかの人に使ってもらう、という流れがやりやすくなることが大きなポイントだと思います。

アドホックなデータ分析

既に作成したデータマートを使い、ビジネス指標のモニタリングや機械学習予測を行っているようなケースで、傾向の変化や性能の劣化を確認した際の、元データの分析です。

このような場合にはどうしてもアドホックにデータを分析して根本的な原因の確認と対策を実施する必要があります。

分析用のコンピュート資源やデータエンジニアの工数がなかったとしても、マネージドで簡単にデータレイクの大きなデータに対して分析環境を準備できるAmazon Athena for Apache Sparkがあれば、スムーズに調査・改善をできる可能性が高まります。

SQLよりPythonの方がいいのか

この点は意見が分かれるところかと思います。一概にApache Sparkでの分析がAthena SQLでの分析より優れているとは言えないでしょう。

個人的には以下のように考えています。

• Pythonの方が、SQLでは簡潔に書けない処理をより簡潔に書く表現力があるということは、ある程度正しいと思われる。特に関数を使うことで行数を減らし、保守性を高めやすい。
• PySparkを使ったアプリケーション開発をするよりも、SQLを使った開発をする方が難易度は低いと思うので、Athena SQLでできる範疇の用途であれば、Athena SQLをエンジンとして使うので良い。
• Pythonは既存のテスト用ライブラリを使うことでテストしやすい言語だと思うが、SQLでもdbtなどのツールを使ってテストできる。開発プロジェクトとして、テストをどのように実現するかの設計次第と考えられる。
• ノートブックで分析処理を共有できる利点は大きい。Athena SQLであればどうしても「SQLファイル + 実行の仕方」の説明を共有することになると思うが、ノートブックであれば説明を含めてノートブックファイルを共有するだけで済む。

最後に

AWS re:Invent 2022の、セッション番号ANT209の『Build interactive analytics applications』の内容を踏まえつつ、このセッションで紹介されたAmazon Athena for Apache Sparkのメリットや使い方について私の考察をまとめてみました。

参考になりましたら幸いです。